Identity and access management (IDM) is an important component of computing based systems and networks. The purpose of an IDM is to allow legitimate users to access resources. IDM systems have evolved over the years, from centralised to distributed access control, from multiple logons to a single sign-on mechanism, from backend federation to frontend federation, and so on. The appropriate nature of IDM depends on the nature of the whole system.
The introduction of distributed systems such as Cloud brings new features and challenges for IDM systems. Cloud provides an abstraction of unlimited resources to consumers. The resources of a cloud are shared among the consumers (tenants) using a concept called multi-tenancy. This allows multiple tenants to share (use) the same physical resource on a pay per use basis. One of the main characteristics of the cloud system is scalability and elasticity. Scalability ensures that the cloud abstracted resources increase or decrease (horizontally scale) their capacity based on the load of the system. To ensure this, cloud based services are designed in a modular fashion so that each service can be scaled by adding or deleting an instance of that service. This also applies to the identity and access management system.
In the cloud, the cloud service provider (CSP) will require an easy way to control access to resources in the system. One way of addressing this requirement is with a centralised IDM solution. One possible approach for centralised access control is illustrated in FIG. 1, which is a schematic diagram of elements of a network 100 including a client 101, identity server 102, and two service providers 103, 104. If the client 101 wishes to access a service provided by one of the service providers 103, it authenticates itself with the identity server 102. As a result of authentication process an assertion token is returned to the client 101. This token is subsequently used by the client 101 to provide proof of identity (and/or of authorisation to use the requested service) to the service provider 103, which can be thought of as an identity consumer. It may be that the client is able to access a different service, for example from another service provider 104, without first having to obtain a specific assertion token.
This approach is widely used by many computer systems. A typical network authentication protocol provides mutual authentication in a client-server fashion (i.e., the client and the server authenticate each other). One possible approach involves the client authenticating with the Authentication server to receive a ‘Ticket’ for a particular service. The ‘Ticket’ is further used to access the desired service. The drawback of this approach is the centralised authentication server, which represents a single point of failure.
In contrast, distributed authentication mechanisms generally allow users, and parties that rely on proof of identity (identity consumers), to choose an identity provider for authentication from a set of identity providers. This eliminates the need to have a single identity provider for user authentication. The problem with this approach is the establishment of a trust anchor—i.e., to establish trust of an identity provider by the identity consumers.
Centralised identity systems provide easy maintenance and control over the system. However, centralisation is not a good choice for the cloud and distributed systems due to the problem of a single point of failure. In a cloud ready system (application), all components should be elastic and horizontally scalable. Currently available centralised identity management systems do not achieve this property. It would therefore be desirable to achieve both the control flexibility of a centralised identity system and the scalability of a distributed system